In a telecommunications system a user has to authenticate for access to the telecommunications network using some method for network authentication. 3GPP has standardized an Authentication and Key agreement Architecture (AKA) wherein user equipment (UE) and network functionality shares a common key as basis for the authentication. The key is managed at the time for subscription to network services preferably stored on a security card, e.g. a SIM card.
Furthermore, a user requesting access to a network service has to authenticate again with the service e.g. to establish a basis for charging. It is common in the art to base trust between a service provider and an end user on sharing security keys. Thus, there is a considerable problem in the management of such keys which will hamper the development and offering of new services.
In order to remedy the key management problem, 3GPP has been developing a Generic Bootstrapping Architecture, (GBA). Basically, the network authentication method is reused in a bootstrapping procedure to create a generic key as basis for generation of further keys related to network services. Therefore, a Network Application Function (NAF), implementing network services and belonging to a specific operator network, may communicate with a network “Bootstrapping Server Function” (BSF) to receive a session key related to the NAF entity. User equipment UE, implementing the same method for authentication as the network, may derive the same generic key and there from derive the same session key.
Thus, the bootstrapping procedure, e.g. GBA bootstrapping, offers a convenient key management that may be used in relation to services offered by a network operator. In the remaining of this document such services will be referred to as internal services. The domain of the key management procedure described above may be extended to incorporate different network operator domains by establishing an inter trust model making it possible for a roaming user UE to establish shared key with a network service in a roaming network.
GBA describes the security features and a mechanism to bootstrap authentication and key agreement for application security from the 3GPP AKA mechanism (3GPP TS 33.220 Generic Bootstrapping Architecture). The GBA architecture enables distribution of shared secrets to both user equipment UE and Network Application Functions NAF. GBA implies modification of certain network entities like “Home Subscriber Server” (HSS) and “Subscriber Locator Function” (SLF) and introduces a new element “Bootstrapping Server Function” (BSF) that implements key management functionality.
3GPP has further developed an evolved GBA infrastructure, “Generic Authentication Architecture” (GAA) extending the scope of GBA to include additional authentication procedures between the end user and applications (3GPP TR 33.919 Generic Authentication Architecture). Operators have emphasized a structure wherein GBA/GAA is deployed through an http-proxy. TS 33.222 specifies an Authentication Proxy, (AP), which is defined as a reverse http-proxy operating as a NAF entity for the UE on behalf of one or more Application Servers. The use of an authentication proxy, AP, is advantageous, e.g. providing:                Reduced Authentication Vector (AV) consumption and synchronization failures        Relief of Application Servers (AS) from performing security tasks (AP handles TLS protocol for secure transport and user authentication towards UE)        Application servers' perception of SSO.        
Insofar as the GBA infrastructure offers convenient access to internal services, there are a growing number of services offered through public networks such as the Internet. This type of services will be referred to as external services.
In order to leverage trust relationships in a public network the Liberty Alliance Consortium has developed an infrastructure, Liberty Alliance Identity Federation Framework (ID-FF), offering single sign-on (SSO) and session management. Basically, a user should need to authenticate only once with any one service provider (SP) within a network of federated providers. An Identity Provider (IdP) maintains information about all service providers being members of the federation. IdP, on request from a user identified by means of a pseudonym, asserts that the user has authenticated with a specified SP. The SP being accessed verifies the assertion and allows the service access.
The Liberty Alliance consortium is committed to developing an open standard for federated network identity offering businesses, governments, employees, and consumers a more convenient and secure way to control identity information. It is a key component in driving the use of e-commerce and personalized data services, as well as Web-based services.
The ID-FF framework attracts great interest from mobile operators in the business role as Identity Provider IdP. Mobile operators, therefore, implement SSO using standard protocols to ease interoperability with external Service Providers SP.
In one scenario mobile operators provides WAP access to external services. For this, Liberty has introduced an entity called “Liberty-Enabled Proxy” (LEP), placed in the Identity Provider domain, and typically running inside a WAP gateway or HTTP proxy.
The specification “Liberty ID-FF Bindings and Profiles” (http://www.projectliberty.org/specs/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf) defines the bindings and profiles of the Liberty protocols and messages to HTTP-based communication frameworks. Further, the specification “Liberty ID-FF Protocols and Schema” (http://www.projectliberty.org/specs/draft-liberty-idff-protocols-schema-1.2-errata-v3.0.pdf) defines a core set of protocols that collectively provide a solution for identity federation management, cross-domain authentication, and session management.
Liberty request-response protocol elements are enclosed within a message body according to protocol “Simple Object Access Protocol” (SOAP). SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment developed by the World Wide Web Consortium, W3C (http://www.w3.org/TR/SOAP).
Operators are required to support both infrastructures, GBA/GAA and Liberty ID-FF SSO. In order to leverage inter work between these two infrastructures 3GPP TR 33.980 studies possible inter-working methods. There is a need to improve inter-working methods between the two infrastructures in order to reduce complexity and cost of implementation.